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Abstract 


The system includes first control units (25,30) each with a logical interface for transparent 
communication between workstations, PCs and control unit connected to the first network (17) and 
units connected to second network (46,52,54). Control unit (50), identification units (54,58), operation 
elements (59,57), input-output unit (56) and robot are connected to the second network. 
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Die Erfindung betrifft ein heterogenes Automatisie- 
rungssystem (10) umfassend 

ein erstes physikalisches Netzwerk (15, 17, 20), in dem alle 
angeschlossenen Einrichtungen auf der Grundlage eines 
ersten Kommunikationsprotokolls kommunizieren kon- 
nen und 

wenigstens ein zweites, uber eine erste, als Gateway fun- 
gierende Steuereinrichtung (25, 30), mit dem ersten Netz- 
werk (15, 17, 20) verbundenes physikalisches Netzwerk 
(52, 58, 59; 54, 56, 57, 60), in dem alle daran angeschalte- 
ten Einrichtungen (54, 56, 57, 60) auf der Grundlage eines 
zweiten Kommunikationsprotokolls kommunizieren kon- 
nen, wobei das erste und das zweite Netzwerk sowie das 
erste und zweite Kommunikationsprotokoll verschieden 
sind. 

Der Erfindung liegt die Aufgabe zugrunde, ein System 
und eine Anschaltvorrichtung bereitzustellen, mit ,deren 
Hilfe die Kommunikation insbesondere bei der lnbetrieb- 
nahme, der Konfiguration und der Wartung des Systems 
im gesamten Automatisierungssystem vereinfacht wird. 
Dies erreicht die Erfindung dadurch, da& jede erste Steu- 
ereinrichtung (25; 30) eine logische Schnrttstelle zur im 
wesentlichen transparenten Kommunikation zwischen 
wenigstens einer an das erste Netzwerk (17) angeschalte- 
ten Einrichtung und wenigstens einer an das zweite Netz- 
werk (52; 54) angeschalteten Einrichtung auf der Grundla- 
ge des ersten Kommunikationsprotokolls aufweist. 
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Beschreibung 



Die Erfindung beirifit ein Automatisierungssystem ge- 
maB dem Oberbegriff des Anspruchs 1 und eine Anschalt- 
vorrichtimg gemaB dem Oberbegriff der Anspriiche 13 und 
14. 

Es sind heterogene Automatisierungssysteme bekannt, 
die ein Leitnetzwerk, beispielsweise das Ethernet, und meh- 
rere dem Leitnetz untergeordnete Feldbusse, z. B. einen In- 
terBus-S, umfafit. Die Anbindung eines Feldbusses an das 
Ethernet erfolgt uber sogenannte Gateways. Die an das Et- 
hernet angeschlossenen Gerate kommunizieren uber das 
TCP/IP-Protokoll miteinander, wahrend die an die Feld- 
busse angeschalteten Gerate jeweils verschiedene Kommu- 
nikadonsprotokolle verwenden kpnnen. Alierdings sind die 
bekannten Gateways nicht in der Lage, eine transparente 
Kommunikation zwischen den an das Ethernet angeschalte- 
ten Geraten und den an die untergeordneten Feldbusse ange- 
schlossenen Gerate iiber das TCP/IP-Pro tokoll zu ermogli- 
chen. ~ 

Der Erfindung liegt daher die Aufgabe zugrunde, ein Sy- 
stem und eine Anschaltvorrichtung bereitzustellen, mit de- 
ren Hilfe die Kommunikation insbesbndere bei der Inbe- 
triebnahme, der Konfiguration und der Warning des Systems 
im gesamten Automatisierungssytem vereinfacht wird. 

Das technische Problem lost die Erfindung zum einen mit 
den Merkmalen des Anspruchs 1. 

Der Kemgedanke der Erfindung ist darin zu sehen, eine 
. Datenkommunikation unter Anwendung eines gemeinsa- 
men ProtokoUs fiber, das Leitnetz und alle da mit verbunde- 
nen Feldbusse zu ermoglichen. Insbesondere soil das 
TCP/IP-Protokoll und seine Dienste eine solche einheitlicbe 
Kommunikation zwischen dem Leitnetz und den unterge- 
ordneten Feldbussen sicherstellen. 

Dazu umfaBt das Automatisierungssystem ein erstes phy- 
sikalisches Netzwerk, in dem alle angeschlossenen Einrich- 
tungen auf der Grundlage eines ersten Kommunikationspro- 
tokolls kommunizieren konnen und wenigstens ein zweites, 
uber eine erste als Gateway fungiemde Steuereinrichtung 
mit dem ersten Netzwerk verbundenes physikalisches Netz- 
werk, in dem alle daran angeschalteten Einrichtungen auf 
der Grundlage eines zweiten KommunikadonsprotokoUs 
kommunizieren konnen, wobei das erste und das zweite 
Netzwerk sowie das erste und zweite Kommunikationspro- 
tokoll verschieden sind. Jeder ersten Steuereinrichtung ist 
eine logische Schnitts telle zugeordnet, die eine im wesentli- 
chen transparente Kommunikation zwischen wenigstens ei- 
ner an das erste Netzwerk angeschalteten Einrichtung und 
wenigstens einer an das zweite Netzwerk angeschalteten 
Einrichtung auf der Grundlage des ersten Kommunikations- 
protokolls ermoglicht Es sei angemerkt, daB das zweite 
Netzwerk auch eine einfache serielle Verbindungsleitung zu 
einem tragbaren Rechner sein kann. 

Die logische Schnitts telle unterstutzt insbesondere alle 
Inbetriebnahme-, Warnings- und Archivierungsaufgaben. 
Mit Hilfe dieser Schnittstelle konnen Steuerungspro- 
gramme, Visualisierungsdaten sowie weitere anlagenspezi- 
fische Datensatze zu den entsprechenden Einrichtungen 
transfenert und im laufenden Betrieb Diagnosedaten erfafit 
werden, bzw. zur Arcbdvierung in ein uberlagertes Rechner- 
system transfenert werden. 

Vorteilhafte Weiterbildungen sind in den Unteranspru- 
chen umschrieberL 

Eine, ein Gateway enthaltende Steuervorrichtung ist in 
den nebengeordneten Anspruchen 13 und 14 angegeben. 

Die Erfindung wird nachfolgend anhand der Ausfuh- 
rungsbeispiele in Verbindung mit den Zeichnungen naher 
erlautert. Es zeigen: 
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Fig. 1 die prinzipielle Struktur eines heterogenen Auto- 
matisierungssystems, in dem die Erfindung verwirklicht ist, 
Fig. 2 eine erfindungsgemaBe Steuereinrichtung nach 
Fig. 1, die zwei untergeordnete Feldbusse mit dem Ethernet 
verbindet, 

Fig. 3 die Softwarestruktur der Steuereinrichtung nach 
Fig. 2, 

Fig. 4 den Industrie-PC nach Fig. 1 , der uber den Interbus 
mit zwei untergeordneten Steuerungseinrichtungen verbun- 
den ist, 

Fig. 5 die Softwarestruktur auf dem Industrie-PC und ei- 
ner untergeordneten Steuerungseinrichtung nach Big. 4, die 
uber einen Interbus verbunden sind: 

Die Struktur eines heterogenen Automatisierungssystems 
15 10 ist vereinfacht in Fig. 1 dargestellt An ein iibergeordne- 
tes Netz, in unserem Beispiel das Ethernet 17 r ist ein PC-Sy- 
stem 15 und eine z. B. UNIX-Workstation 20 iiber jeweils 
einen Ethernet- AnschluB angeschaltet. Daruber hinaus ist 
ein Industrie-PC 25 und eine speicherprograrnmierte Steuer- 
einrichtung 30, eine sogenannte Anschaltbaugruppe, an das 
Ethernet 17 angeschaltet, die iiber eine Gateway-Funktiona- 
litat verfugen. In den Industrie-PC 25 sind beispielsweise 
zwei Anschaltkarten 40, 42 eingesteckt, die einen Feldbus 
44 bzw. 46 mit dem Ethernet 17 verbinden. Bei dem Feldbus 
handelt es sich beispielsweise uni den InterBus-S. Eine RFC 
(Remote Field Contiol)-Steuereinrichtung 50, die ebenfalls 
iiber eine Gateway-Funktionalitat verfugt, verbindet den In- 
terbus 44 mit einem weiteren Interbus 52. Die Anschaltbau- 
gruppe 30 verbindet einen weiteren Interbus 54 mit dem Et- 
hernet 17. Es sei angemerkt, dafi beliebig viele Feldbusse 
miteinander oder mit dem Ethernet 17 verbunden sein kon- 
nen. An deh Interbus 54 sind heben Eingabe-/Ausgabe-Bau- 
gruppen 56, Identifizierungssysteme 54 auch Bedienterrni- 
nals 57 mit einfachen Visualisierungsmoglichkeiten und ein 
Roboter 60 angeschaltet An den Interbus-S ist beispiek- 
weise eine Identifizierrngseinrichtung 58 und ein Bedien- 
element 59 angeschaltet 

Alle Gerate, die miteinander kommunizieren konnen, bil- 
den zusammen ein logisches Netzwerk. Voraussetzung fur 
eine Kommunikationsbeziehung zwischen Geraten in einem 
logischen Netzwerk ist neben der physikalischen Verbin- 
dung in erster Linie ein gemeinsames Kornmunikadonspro- 
tokolL 

Das Ethernet 17 benutzt als KornmunikationsprotokoU 
das TCP/IP-Protokoll, fiber das der PC 15, die Workstation 
20, der Industrie-PC 25 und die Interbus-Anscbaltbau- 
gruppe 30 miteinander kommunizieren konnen. 

Folgende Funktionen werden von dem TCP/IP-Protokoll 
iiber das Ethernet 17 im aUgememen unterstutzt: 
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a) Herunterladen von Steuerungsprogrammen und 
Konngurationsdaten iiber das Ethernet auf die INTER- 
BUS Anschaltkarten 40, 42 des Industrie-PCs 25 oder 
der Anschaltbaugruppe 30 mit Emernt-SchnittsteUe, 

b) Archivierung von Programmen und Parametersat- 
zen in der Workstation 20, - 

c) Diagnose der angeschalteten Feldbusse 44, 50 und 
52 und 

d) "Obertragung von Visualisierungsdaten iiber das Et- 
hernet 

Der Interbus 44, 54 oder 52 benutzt neben einem ProzeB- 
datenkanal einen Parameterkanal zur Ubertragung von Da- 
ten. "Ober den Parameterkanal konnen komplexe und urn- 
fangreichere Daten zwischen zwei Interbus-Teilnehmem 
iibertragen werden. Dieser Kanal wird insbesondere ver- 
wendet, urn beispielsweise die Displays von den Bedienter- 
minals zu aktualisieren, oder urn Steuerungsprogramme auf 
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die unterlagerte Steuereinrichtung 50 uber den Interbus 44 
zu ubertragen. Das Kommunikationsprotokoll, das fur die 
Datenubertragung uber den Parameterdatenkanal des Inter- 
bus verwendet wird, heifit Peripheral Communication Proto- 
col (PCP). 

Jn Fig. 2 ist ein Ausschnitt aus dem Szenario nach Fig. 1 
dargestellL Der Industrie-PC 25, der in diesem Fall als 
Steuerungsrechner fungiert, ist iiber das Ethernet 17 mit 
dem ubergeordneten Rechnersystem 15 verbunden. Ein En- 
gineering-Rechner 70, der hier stilisiert als Laptop darge- 
stellt ist, realisiert eine Verbindung zum Industrie-PC 25 
uber eine serielle Verbindung (V24). Die Steuerung der In- 
terbusse 44 und 46 wird mit Hilfe der beiden verschiedenen 
PC-Anschaltkarten 40, 42 im Steuerungsrechner 25 urnge- 
setzt Die PC-Anschaltkarte 40 sei beispielsweise die IBS 
ISA FC/I-T und die PC-Anschaltkarte 42 die IBS ISA 
FC/486 DX/I-T mit einem Coprozessor. Zusatzlich beinhal- 
tet der Industrie-PC 25 neben den standardmaBig vorhande- 
nen Massenspeichern, eine (PCMCIA) PC-Karte als Spei- 
chermedium fur alle Steuerungsprogramme und die wesent- 
lichen Konfigurationsdaten z. B. fiir die Visualisierung. 

Die erfindungsgemaBe einheitliche Komrnunikations- 
struktur auf der Basis von TCP/IP vereinfacht im wesentli- 
chen die folgenden Datenubertragungeri: 

Herunterladen und Hinaunaden von Steuerungsprograrn- 
men, 

die tJbertragung von Konfigurationsdaten fiir Steuerungen 
und Visualisierungen, 
die Obertragung von Diagnosedaten und 
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17 zu ubertragen. t)ber diesen Weg kann auch die Visuali- 
sierung des PC WORXremote mit Daten versorgt werden. 
tJber einen Loader konnen Steuerungsprogramme und die 
notwendigen Konfigurationsdaten auf die Anschaltkarten 
40,42 heruntergeladen werden. Dieser Vorgang kann aller- 
dings nicht von einem entfernten Host initiiert werden. 

Downloads und Uploads von Daten konnen in dem 
TCP/IP-basierten Ethernet mit Hilfe des FTP-Dienstes reali- 
siert werden. Da dieser Dienst eine Client/Server-Struktur 
vorsieht, muB auf dem Zielsystem immer ein FTP-Server 
verfugbar sein. Mit Hilfe eines FTP-Qients konnen dann 
Daten an und vom Industrie-PC 25 ubertragen werden. 
Windows NT bietet standardmaBig einen im System inte- 
grierten FTP-ClienL Mit Hilfe des FTP-Dienstes konnen 
Steuerungsprogranime sehr komfortabel auf den Industrie- ■ 
PC heruntergeladen werden. Der FTP-Server verwendet da- 
bei das Dateisystem (oder eine PC-Karte) des Industrie-PCs, 
urn die empfangenen Daten zu speichern. Von dort kann ein 
IB-Loader verwendet werden, urn die Programme auf die 
Anschaltkarten 40, 42 zu transferieren. Um eine moglichst 
einheitliche und durchgangige Konimunikatiortsinfras truk- 
tur im gesamten Automatisierungssystem 10 zu erreichen, 
muss en Steuerungsprogramme und Konfigurationsdaten mit 
dem FTP-Dienst auf die PC-Anschaltkarten 40, 42 herunter- 
geladen werden. Die hierfiir notwendigen Anpassungen sind 
abhangig von der unterlagerten PC-Anschaltkarte 40, 42. 

Die in Fig. 3 gezeigte Anschaltkarte 42 mit einem Copro- 
zessor 85, wie die IBS ISA FC/486 DXfl-T oder die IBS 
S7/400 DSCVETH, bietet die Moglichkeit, einen eigenen 



die Obertragung von Daten an die Anzeigeeinrichtung der 30 TCP/EP-Protokollstapel zu implementieren, und sie besitzet 
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Bedienterminals 

Die nachfolgend in Verbindung mit Fig* 3 beschriebene 
Softwarestruktur ist auf dem Industrie-PC 25 notwendig, 
um die erfindungsgemaBe TCP/EP-Kommunikations struktur 
zu unterstutzen. 

Um die Kommunikation zwischen dem Industrie-PC 25 
und dem ubergeordneten PC 15 zu verdeutlichen, ist auch 
dieser in der Fig. 3 dargestellL Der Engineering-Rechner 70 
ist nicht gezeigt Er verhalt sich aber kommunikationstech- 
nischwie der Industrie-PC 25, mit dem Unterschied, daB 
eine Verbindung zwischen dem Industrie-PC 25 und Engi- 
neering-Rechner 70 in diesem Beispiel uber die serielle 
Schnittstelle erfolgt 

Im oberen Bereich der Fig. 3 ist der ubergeordnete PC 15 
schematisch dargestellL PC WORX kann auf diesem PC 15 
beispielsweise verwendet werden, um Diagnosedaten vom 
unterlagerten Industrie-PC 25 zu holen, oder um die unterla- 
gerten Interbusse 44, 52 und 54 zu visualisieren. 

Im rnittleren Bereich der Fig, 3 ist die Softwarestruktur 
des Industrie-PCs 25 dargestellL Eine Kommunikation auf 50 
der Basis des TCP/BP-Protokolls kann uber den Ethemet- 
NetzwerkanschluB und/oder fiber eine serielle Schnittstelle 
des Hauptrechners 80 des Industrie-PCs 25 ermoglicht wer- 
den. tJber die serielle Leitung wird das Point-to-Point-Pro- 
tocol (PPP) unterstutzt. Dieses Protokoll kapselt das 
TCP/IP-Proiokoll in eine geeignete Form, so daB eine seri- 
elle Obertragung (beispielsweise uber ein Modem) moglich 
isL 

Auf dem Industrie-PC 25 kann ein VisualisierungsprozeB 
laufen, der z. B. uber das Open Com Interface (OCI) auf Da- 
ten des Prozesses zugreift Sollen diese Daten an einen uber- 
lagerten, an das Ethernet 17 angeschalteten Visualisierungs- 
rechner ubertragen werden, muB auf dem Industrie-PC 25 
ein ServerprozeB (Ethernet-DDI-Server, nicht abgebildet) 
laufen, der die fiber das Ethernet 17 empfangenen DDI- 
Kommandos an die Geratetreiberschnittstelle DDI (engL: 
Device Driver Interface) durchreichL SYSTEM WORX ist 
in der Lage, DDI-Dienste per Datagramm liber das Ethernet 
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somit auch eine eigene IP-Adresse, mit der sie eindeutig in 
dem Automatisierungssystem 10 identiriziert werden kann. 
Hat der Coprozessor 85 keinen Ethernet- AnschluB , so ist die 
einzige Schnittstelle, die den Coprozessor 85 mit dem uber- 
lagerten Hauptrechner 80 verbindet, ein Mehrtorspeicher 
MPM (engl.: Muld Port Memory). Deshalb miissen alle 
uber den FTP-Dienst transferierten Daten uber das MPM 
ubertragen werden. Auf dem Coprozessor 85 miissen diese 
Daten uber Dienste des DDI geholt werden und wieder in 
TCP/lP-Rahmen umgesetzt werden. Diese Aufgabe obliegt 
einem speziellen ServerprozeB, der auf dem Coprozessor 85 
unter VxWorks laufL "Ober den TCP/IP-Protokollstapel kon- 
nen die Daten dann an einen FTP-Server, der zusatzlich auf 
dem Coprozessor 85 lauft, durchgereicht werden. Auf dem 
uberlagerten Hauptrechner 80 muB zudem ein spezieller 
TCP/DDI-NDIS-Treiber vorhanden sein. Daten, die uber 
die Ethernet-Schnittstelle oder uber PPP von der seriellen 
Schnittstelle kommen und fur die unterlagerte PC-Anschalt- 
karte 42 bestimmt sind, miissen direkt auf diesen Treiber 
umgeleitet (geroutet) werden. Dies ist allerdings nur dann 
realisierbar, wenn im Industrie-PC 25 eine entsprechende 
Routinginformation zur Verfugung stehL 

Weist der Coprozessor 85 der Anschaltkarte 42 hingegen 
einen Ethernet- AnschluB auf, ubemirnmt der auf diesem 
Coprozessor 85 arbeitende TCP/IP-Stapel alle diese Aufga- 
ben. 

Im Gegensatz zur Anschaltkarte 42 mit dem Coprozessor 
85 verfugt die einfache Anschaltkarte 40 nicht iiber genii- 
gend Res sour cen, um einen eigenen TCP/EP-Protokollstapel 
zu ermoglichen. Da sie folglich auch keine IP-Adresse besit- 
zen kann, muB ein sogenannter Stellvertreter oder Proxy- 
Server auf dem ubergeordneten Hauptrechner daftir sorgen, 
daB die Anschaltkarte 40 im Automatisierungssystem 10 
adressiert werden kann. Ein solcher Proxy-Server iiber- 
nimrnt die Rolle eines FTP-Servers, empfangt die herunter- 
geladenen Daten stellvertretend fur die unterlagerte An- 
schaltkarte 40, und transferiert diese Daren dann iiber das 
MPM mit Hilfe der hierfiir erforderlichen Dienste eines In- 
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terbus-Masters. 

Fig, 4 zeigt einen einen Ausschnitt des Automatisierungs- 
systems 10 nach Fig, 1, in dem der uberlagerte Industrie-PC 
25 iiber den Interbus 44- mit der unteriagerten Steuerungs- 
einrichtung 50 und einer weiteren •unteriagerten Steuerungs- 
einrichtung 90 verbunden ist Bei den direkt unteriagerten 
Steuerungseinrichtungen 50 und 90 handelt es sich bei- 
spielsweise um eine Fernfeld-S teuereinrichtung RFC (engL: 
Remote Field Controller (LBS 24RFC/ 486 DX) und zum an- 
deren um einen Steuerungs-PC 90 mit einer Interbus-PC- 
Anschaltbaugruppe. Der unterlagerte Steuerungs-PC 90 
steuert einen Interbus 92, in den wiedeium eine dezentrale 
Steuerungseinrichtung 95 (IBS KT 24 DIO 16/16-T) als 
Slave integriert ist 

. Steuerungsprogramme und Konfigurationsdaten sollen 
mit Hilfe des FTP-Dienstes vom ubergeordneten Industrie- 
PC 25 iiber den Interbus 44 auf die unteriagerten Steue- 
rungseinrichtungen 50, 90 heruntergeladen werden. Erfor- 
derlich ist hierzu die t)bertragung der TCP/IP-Datenblocke 
iiber den Interbus 44. Damit mterbus-Teimehmer fiber den 
TCP/TP-Dienst FTP direkt angesprochen werden konnen,: 
miis sen sie eine IP-Adresse haben. Die Steuerungseinrich- 
tungen 50 und 90 besitzen genugende Ressourcen, um einen 
eigenen vollwertigen TCP/EP-Protokollstapel zu ennogli- 
chen, mit dem eine IP-Adresse assoziiert werden kann. Da 
als tibertragungsmedium zwischen dem ubergeordneten In- 
dustrie-PC 25 und den unteriagerten Steuerungseinrichtun- 
gen 50 und 90 der Interbus 44 fungiert, kann der Zugriff auf 
' die unteriagerten Steuerungseinrichtungen 50, 90 nicht mit 
den Standardverfahren realisiert werden, die in dem Ether- 
net 17 selbstverstandlich sind. Zwischen dem Ethernet 17 
und dem Interbus 44 muB insofern ein Gateway daftir sor- 
gen, daB die Verbindung zustande kommt Die IP-Adiessen 
aller Interbus-Teilnehmer mussen in einem dem Interbus 44 
Ubergeordneten Namensserver abrufbar sein. \ 

Da die Interbus-Teilnehmer keine regularen Ethernet-Ge- 
rate sind, mufi der Namensserver ebenso die fur den jeweili- 
gen Interbus-Teilnehmer zustandigen Steuerungsrechner be- 
inhalten. Mit anderen Worten ist in dem Namensserver die 
IP-Adresse beispielsweise der S teuereinrichtung 50 und die 
der Identifizierungseinrichtung 58 und des Bedienterminals 
59 abgelegt TCP/IP-Dienste, die z. B. an den Teilnehmer 58 
des Interbusses 52 gerichtet sind, gehen zuerst an den zu- 
standigen Proxy-Server der S teuereinrichtung 50. Die IP- 
Adresse wind dann auf eine Interbus-spezifische Kommuni- 
katiohsreferenz abgebildet, mit der eine Verbindung zwi- 
schen zwei Interbus-Teilnehmern fiber den Parameterdaten- 
kanal beschrieben wird. Die empfangenen TCP/IP-Daten- 
blocke werden dann in PPP-Rahmen gekapselt und mit 
Hilfe einer Sequenz von PCP-Dienstaufirufen (Fragmentie- 
rung der Daten) an den entsprechenden Interbus-Teilnehmer 
58 Ubertragen. Die t)bertragung der Daten kann entweder 
vom Proxy-Server selbst oder mit einem entsprechenden 
PPP/PCP-NDIS-Treiber an def Steuerungseinrichtung 50 
vorgenommen werden. 

Auf der unteriagerten Steuerungseinrichtung 50 und 90 
muB ein Treiber oder Server-ProzeB) vorhanden sein, der 
fiber die Interbus- Slave-Anschaltung Zugriff auf den Para- 
meterdatenkanal besitzt Dieser Treiber wandelt die PCP- 
Rahmen wieder in TCP/IP-Rahmen (bzw. PPP-Rahmen) 
um. Ober den TCP/EP-Protokollstapel gelangen die Daten 
dann beispielsweise an einen FTP- Server. Das Ergebnis des 
Dienstaufrufs wird vom Interbus-Teilnehmer fiber den Para- 
meterdatenkanal entweder fiber den Treiber oder direkt an 
den Proxy-Server der entsprechenden als Gateway fungie- 
renden S teuereinrichtung zurfick geliefert.Von dort werden 
die Daten dann an das aufrufende System ubertragen. 
Die Obertragung von Daten an einfache dezentrale Steue- 
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rungseinrichtung (nicht dargestellt), die nicht genugend 
Ressourcen besitzet, um einen TCP/TP-Protokollstael zu er- 
moglichen, ist wiederum fiber den Proxy-Server auf der je- 
weiligen Steuereinrichtung moglich. Da die unterlagerte 
Steuerungseinrichtung nicht TCP/EP-fahig ist, muB ihr eine 
virtuelle IP-Adresse zugeordnet werden. Diese sollte, wie 
auch alle realen IP-Adressen, im gesamten Automarisie- 
rungssystem 10 eindeutig sein und vom zentralen Namens- 
server verwaltet werden. Das Herunteriaden von Steue- 
ningsprogrammen von einer ubergeordneten Steuerungsein- 
richtung fiber den TCP/EP-Dienst FTP wird fiber den Proxy- 
Server umgesetzt Stellvertretend fur die unterlagerte Steue- 
rungseinrichtung wird der FTP-Dienstaufhif vom Proxy- 
Server bearbeitet Uber die Abbildung der virtuellen IP- 
Adresse auf die Kommunikationsrerefenz bestimmt der 
Proxy-Server den richtigen Interbus-Teilnehmer und emu- 
liert den FTP-Dienst, indem die entsprechenden Interbus- 
Dienstaufrufe (DDI) verwendet werden, die fiir ein Herun- 
terladern der Software auf die Anschaltung notwendig sind. 
Die Ergebnisse des Herunteriadens werden fiber den Proxy- 
Server in adaquater Form (FTP-konform) an den FTP-Qient 
zuriickgegeben. 

In Fig. 5 ist die grobe Softwarestruktur fur den als Gate- 
way fungierenden Industrie-PC 25 und die unterlagerte 
Steuerungseinrichtung 50 vom TVp IBS 24 RFC/DX486 mit 
dem TCP/EP-Protokollstapel zu sehen. 

Handelt es sich bei der unteriagerten Steuerungseinrich- 
tung 50 um eine PC-basierte Steuerungseinrichtung, die den' 
unteriagerten Interbus 52 steuert, dann befinden sich minde- 
stens zwei Interbus- Anschaltungen in diesem System, Ober 
eine Slave-Anschaltung ist die Steuerungseinrichtung 50 
mit dem ubergeordneten Interbus 44 verbunden. Die Steue- 
rung des unteriagerten Interbus 52 ubernimmt eine Master- 
Anschaltung. ^ 

Die fiber den Parameterdatenkanal des Interbusses 44 
empfangenen Daten werden fiber einen PCP/PFP-NDIS- 
Treiber wieder in PPP-Rahmen umgewandelt und fiber den 
TXJP/EP-Protokollstack zum Beispiel an den FTP-Server . 
durchgereicht 

Damit Daten auch fiber mehrere als Gateways fungie- 
rende Steuereinrichtungen - beispielsweise die Steuerein- 
richtungen.25 und 50- hinweg an unterlagerte Interbusse 
transportiert werden konnen, muB auf jedem, zwei Inter- 
busse verbundenen Gateway, das TCP/IP oder TCP/IP fiber 
PCP unterstutzt, ein Interbus Proxy-Server vorhanden sein. 
Der Proxy-Server verwaltet alle unteriagerten Interbus-Teil- 
nehmer, die PCP unterstutzen. Damit diese Teilnehmer mit 
einem TCP/EP-Dienst angesprochen werden konnen, muB 
der Proxy-Server die IP-Adressen der unteriagerten Teilneh- 
mer kennen und auf eine Interbus-spezifische. Kommunika- 
uonsreferenz abbilden konnen. Der Proxy-Server verwendet 
einfache Namenstabellen, um unterlagerte Steuerungsein- 
richtungen und Interbus-Teilnehmer fiber den Interbus mit 
TCP/IP-Dienste wie FTP anzusprechen. Eine Kommunika- 
tion mit fiberlagerten Steuerungseinrichtungen ist nur dann 
moglich, wenn die unterlagerte Steuerungseinrichtung 
Kenntnis darfiber besitzen, wie fiberlagerten Steuerungsein- 
richtungen zu erreichen sind (fiber welche Gateways etc.) 
In einem Interbus wird die Verbindung zum fiberlagerten 
Gateway grundsatzlich fiber die Master- Anschaltung des 
entsprechenden Interbus-Subnetzes erreicht Das direkt 
fibergeordnete Gateway kann von unteriagerten Busteilneh- 
mern somit problemlos angesprochen werden. Verbindun- 
gen zu fiberlagerten Systemen fiber mehrere Gateways hin- 
weg sind nur dann moglich, wenn der jeweilige Teilnehmer 
die notwendige Route kennt Sinnvollerweise wird die hier- 
fur notwendige Logik in den Proxy-Server veriagert, der auf 
jedem Gateway notwendig ist. Da der Proxy-Server Kennt- 
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nis iiber die Adressen der gesamten unterlagerten Interbus- 
Teilnehmer und iiber die Adresse des nachsten iiberlagerten 
Gateways besitzt, werden Dienste, die an andere EP-Adres- 
sen gehen grundsatzlich zum nachsten Gateway durchge- 
reicht, bis die zustandige Steuenmgseinrichtung gefunden 
ist Auf der Ebene des Ethernets sorgt der speaelle Namens- 
server, der die gesamten IP- Adressen des Automatisierungs- 
systems verwaltet, dafur, dafi alle IP- Adressen (auch die vir- 
tuellen Adressen) aufgelost werden, bzw. das die korrekten 
Routen identifiziert werden. 

Eine wesentliche Voraussetzung fur die Integration von 
Feldbus-Teilnehmern in eine Kommunikationsstruktur auf 
der Basis von TCP/IP ist zum einen die physikalische Ver- 
bindung zwischen Netzwerk und Teilnehmer und zum ande- 
ren die eindeutige IP-Adresse des jeweiligen Teilnehmers 
im Netzwerk. Die physikalische Verbindung zwischen den 
unterschiedlichen Ubertragungsmedien (wie zum Beispiel 
Ethernet und Interbus) kann, wie bereits beschrieben, uber 
Gateways umgesetzt werden. Hier kommen entweder PC- 
basierte Steuerungseinrichtungen mit Netzwerkkarte und 
Interbus- Anschaltungen, oder Ethemet-RFC (IBS 24 RFC/ 
486DX/ETH-T) zum Einsatz. Die Verbindung zwischen ei- 
nem iiberlagerten und einem unterlagerten Interbus wird 
auch mit Hilfe von als Gateways fungierenden Steuerein- 
richtungen umgesetzt, obwohl beide physikalischen t)ber- 
tragungsmedien identisch sind. Gateways sind im Automati- 
sierungssystem 10 grundsatzlich Steuerungseinrichtungen, 
die einen unterlagerten Feldbus steuem. Je nach Art des un- 
terlagerten Feldbus-Teilnehmers erfolgen Dalenubertragun- 
gen (wie Downloads und Uploads) zwischen Gateway und 
diesem entweder iiber 
TCP/IP, 

TCP/IP iiber PCP (PCP+), 
oder PCP. 

Steuerungseinrichtungen, die keinen eigenen TCP/TP- 
Protokollstapel besitzen, miissen iiber virtuelle IP- Adressen 
angesprochen werden konnen, Das Gateway mufi als Stell- 
vertreter des untedagerten 

Busteilnehmers eine entsprechende Namenszuordnung urn- 
setzen. l)ber die Anschaltbaugruppe des Gateways konnen 
Kommuni kationsref erenzen definiert werden, mit denen 
PCP -Verbindungen zwischen zwei PCP-fahigen. Busteil- 
nehmem charakterisiert sind. Prinzipiell kann iiber die An- 
schaltbaugruppe eine PCP-Kommunikation zu jedem Bus- 
teilnehmer mit PCT-Fahigkeit auf gebaut werden. Mit Hilfe 45 
einer geeigneten Abbildungsfunkdon von Kommuni kati- 
onsreferenz auf virtuelle IP kann einem Busteiinehmer eine 
eindeutige IP-Adresse zugeordnet werden. Diese Abbildung 
wird in einem iibergeordneten Namensserver und auf dem 
jeweiligen Gateway-Rechner verwaltet 

Fur die Realisierung dieser Struktur miissen im wesentli- 
chen drei Sofrwarekomponenten umgesetzt werden: 
Interbus-Proxy-Clients fxir alle direkt im Netzwerk befindli- 
chen Rechnersysteme, 

Interbus Proxy-Server fur die entsprechenden Gateway- 
Rechner, 

PCP/PFP-NDIS-Treiber fur PC-basierte Rechnersysteme, 
die iiber eine Slave- Anschaltung mit dem Interbus und so- 
mit mit dem Gateway verbunderi sind, 
PCP/FPP-Server-ProzeB fur dezentrale Steuerungen wie der 
IBS 24RFC/486DX. 

Interbus Proxy-Clients miissen zwischen realen und virtu- 
ellen IPs unterscheiden. Die meisten TCP/EP-Dienste, wie 
Telnet, Ping, oder FTP, erfordem die Angabe einer IP- 
Adresse, die kennzeichnet, welcher Host angesprochen wer- 
den solL Unter Windows NT und in vielen anderen Betriebs- 
systemen wird eine spezielle Softwarebibliothek (Socketli- 
brary) verwendet, um netzwerkspezifische Funktionen, wie 
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Verbindungsaufbau, Dateniibertragungen und die Namens- 
auflosung durchfuhren zu konnen. Da alle TCP/IP-Stan- 
darddienste diese Bibliothek verwenden, muB der Proxy- 
Client noch vor dem Aufiruf der Funktionen der eigentlichen 
Socket-Bibliothek die aufgerufene IP-Adresse iiberpriifen, 
um zu testen, ob es sich um eine virtuelle oder eine reale IP 
handelL ImFalle einer realen IP-Adresse konnen alle Funk- 
tionsaufrufe an die Socketbibliothek durchgereicht werden. 
Im Gegensatz dazu mufi bei einer virtuellen IP-Adresse der 
Dienst an einen Interbus Proxy-Server durchgereicht wer- 
den, da das gewahlte Gerat ein Teilnehmer des Interbus und 
insofem nicht direkt im Netzwerk erreichbar ist. Den zu- 
standigen Proxy-Server kann der Proxy-Client entweder 
iiber eine Lokale oder eine zentrale Abbildungstabelle in ei- 
ner Datenbank (Namensserver) ermitteln. Diese Tabelle be- 
inhaltet alle einem Proxy-Server zugeordneten virtuellen IP- 
Adressen. 

Neben der Verwendung virtueller IP-Adressen, besteht 
auch die Moglichkeit, einer Netzwerkkarte mehrere IP- 
Adressen zuzuordnen. Ein Gateway-Rechner konnte in die- 
sem Fall alle IP-Adressen der unterlagerten Interbus-Teil- 
nehmer auf die eigene Netzwerkkarte abbilden. Eine zen- 
trale Namensverwaltung und der Proxy-Client sind in die- 
sem Fall uberflussig. Jeder TCP/IP-Dienst, der mit einer IP- 
Adresse der untedagerten Interbus-Teilnehmer aufgerufen 
wird, mufi auf dem Gateway-Rechner abgefangen und an 
den unterliegenden Interbus-Teilnehmer weitervermittelt 
werden. Jeder Aufruf eines TCP/IP-Dienstes wird vom 
Proxy-Server analysiert "Wird dabei die definierte IP- 
Adresse eines unterlagerten Interbus-Teilnehmers gefunden, 
wird der Aufruf in PPP-Rahmen gekapselt und mit Hilfe der 
entsprechenden Interbus-Dienste uber den Parameterdaten- 
kanal an den zustandigen Empfanger ubertragen. Nachteil 
dieses Ansatzes ist die Menge der gleichzeitig mit der Netz- 
werkkarte gebundenen IP-Adressen. Von Windows NT wer- 
den zur Zeit nur funf unterschiedliche IP-Adressen unter- 
stiitzt 

Der Interbus Proxy-Server lauft auf Gateway-Rechnem 
und ist verantwortlich fur die TCP/IP-b asierte Kommunika- 
tion zwischen Systemen iiber den Interbus. Zu den Aufga- 
ben des Proxy-Servers zahlen: 

Erzeugung und Verwaltung virtueller "PPP iiber PCP' -Ver- 
bindungen zu unterlagerten und iibergeordneten Systemen, 
Emulation von TCP/EP-Diensten stellvertretend fur Inter- 
bus-Teilnehmer ohne TCP/IP-Protokollstapel, 
Bereitstellung des "Remote-DDI" fur Konfiguration, Visua- 
lisierung, 

Verwaltung lokaler Namentabellen mit virtuellen IP-Adres- 
sen unterlagerter Systeme, 

Synchronisation der lokalen und globalen Namenseintrage 
Routing. 

Der Proxy-Server verwaltet alle Verbindungen zwischen 
unterlagerten und iibergeordneten Systemen . 

Um eine ausreichende Flexibilitat zu gewahrleisten, muB 
der Proxy-Server mehrere simultane Verbindungen verwal- 
ten konnen. Da auch Verbindungen iiber mehrere Ebenen 
(und entsprechend mehreren Gateways) umgesetzt werden 
sollen, mufi der Proxy-Server zu einer gegebenen IP- 
Adresse auch den Pfad ermitteln konnen. tjber die Verwen- 
dung von statischen Routingtabellen, in denen alle unterla- 
gerten Systeme in geeigneter Form eingetragen sind, kann 
die Route zu einem bestimmten unterlagerten Teilnehmer 
gefunden werden. Die Route zu einem iiberlagerten System 
kann nur durch einen Nachrichtenaustausch mit iiberlager- 
ten Gateways festgelegt werden. Die Verbindung mufi so 
unter Umstanden iiber mehrere Gateways, bzw. deren 
Proxy-Server realisiert werden. Proxy-Server fungieren hier 
als Software-Router. Fur diesen Zweck werden auch lokale 
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Namenstabellen vom Proxy-Servem angelegt und verwaltet 
Da der Proxy-Server fur das Anlegen der Tabellen zustandig 
ist, miissen zusatzlich die lokalen Daten mit den globalen 
Daten des globalen Namensservers abgeglichen werden. 

Fur Busteilnehmer ohne die Moglichkeit eines eigenen 
TCP/IP-Protokolistapels miissen Proxy-Server zudem die 
wesentlichen TCP/EP-Dienste emulieren. Sinnvollerweise 
muB hier eine geeignete Auswahl an verfugbaren Emulati- 
ons diensten vorgenommen werden. Zusatzlich sollte der 
Proxy-Server als Ethemet-DDI-Server fungiereri, so daB 
Konngurationstools und Visualisierungen "remote" auf das 
DDI zugreifen konnen, 

Der Interbus-Proxy-Client wird grundsatzlich automa- 
tlsch vor jedem Aufruf einer Socket-Funktion aktiv. 

Handelt es sich bei diesem Aufiruf urn eine Funktion, die 
als Argument eine IP-Adresse beinhaltet, uberprfift der 
Proxy-Client diese. Erkennt der Proxy-Client eine reale IP- 
Adresse, wird der Aufruf direkt an die entsprechende Sok- 
ket-Funktion durchgereicht. Wird eine virtuelle IP-Adresse 
erkannt, wird der Funktiorisaufruf in ein Datagramm gekap- 
selt und an den entsprechenden Proxy-Server gesendet. Das 
Ergebnis des Funktioris aufiruf s kommt dann entweder direkt 
vom realen Host oder aber vom Proxy-Server in Form eines 
Datagramms. Die Kommunikation zwischen Proxy-Client 
und Proxy-Server wird typischerweise fiber Remote Proce- 
dure Calls umgesetzt 

PC-Steuemngen, die fiber eine Slave- Anschaltung mit ei- 
nem Interbus verbunden sind, benotigen einen NDIS-lrei- 
. ber, der aus den iiber den Interbus empfangenen PCP-Daten 
wieder PPP-Rahmen (und umgekehrt aus PPP-Rahmen wie- 
der PCP-Rahmen) erzeugt Daten, die von der Interbus- An- 
schaltbaugruppe komrnen, miissen vom TVeiber in FPP-Da- 
tenpakete umgewandelt werden. Da das PCP-Protokoll nur 
kleine Datenmengen in einem Dienstautruf . ubertragen 
kann, mufi unter Umstanden eineDefragmentierung der Da- 
ten vorgenommen werden. Zusatzlich muB eine Fehlerbe- 
handlung bei unvollstandigen Daten vorgesehen werden. In 
anderer Richtung miissen empfangene PPP-Datenpakete 
fragmentiert und uber eine Sequenz von PCP-Dienstaufru- 
fen ubertragen werden. 

Da auf PC-Anschaltkarten mit Coprozessor ein TCP/IP- 
Protokolistapel moglich ist, sollte fiber das Multi Port Me- 
mory zusatzlich das Protokoll TCP/IP gefahren werden. 
Dies wfirde zudem ermoglichen, Prozesse, die unter 
VxWorks auf einem Coprozessor-Board aktiv sind, fiber 
TCP/IP "remote" zu debuggen. Notwendig ist insofern ein 
NDIS-Treiber, der sich zum Host wie eine Netzwerkkarte 
verhalt und auf der anderen Seite fiber das DDI auf das Mail- 
box-Interface des MPM zugreaft 

Die Konfiguration eines Automatisierungssy stems kann 
durch den Einsatz einer einheitlichen Kommunikations- 
ebene deutlich vereinfacht werden. Durch die Verwendung 
des de facto Standards TCP/IP kann auf eine groBe Menge 
von sinnvollen Sofrwarewerkzeugen zuruckgegriffen wer- 
den. 

Das File Transfer Protocol (ftp) kann fur die Ubertragung 
von grofien Datenmengen verwendet werden. Downloads 
.und Uploads von Programmen und Konfigurationsdaten 
konnen so in einheitlicher Art und Weise umgesetzt werden. 
Eine weitgehende Autornatisierung kann durch solch eine 
transparente Kommunikation sstruktur erheblich vereinfacht 
werden. 

Umfangreiche Automatisierungssysteme beinhalten ein 
groBe Anzahl von verschiedenen dezentralen Steueriingen. 
Haufig miissen in grofien Anlagen autarke Einheiten ausge- 
tauscht oder neu inibalisiert werden. Diese Bestandteile 
miissen dann moglich st automatiscb wieder Hochfahren. In 
PC-basierten Steuemngseinrichtungen und in Femfeld- 
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Steuereinrichtungen, konnen Steuenmgsprogramme und an- 
dere Konfiguraiionsdaten auf eine PC-Karte (Hash-Me- 
mory, AIA-Drive etc. siehe auch Anhang A) gespeichert 
werden. Wahrend des Bootvorgangs konnen fiber den FTP- 
Dienst wieder alle Daten von diesen Speichermedien auf die 
unterlagerten Steuerungen heruntergeladen werden. 

Auch die Oberwachung des Automatisierungssystems 
wird durch den Einsatz des TCP/TP-Protokolls unterstiitzt 
Angefangen von einfachen Monitoring — fiber komplexe 
Fern w artungsmoglichkeiten lassen sich auf der Grundlage 
von TCP/IP viel Einsatzgebiete abdecken. ZumoBeispiel 
kann der einfache Ping-Dienst verwendet werden, urn zu 
iiberprufen ob ein System im Netzwerk vorhanden ist Weit 
rnehr Moglichkeiten bietet das Simple Network Manage- 
ment Protocol. Dieses Protokoll bildet die Grundlage fur 
viel modeme Netzwerkmanagement-Anwendungen. 

Die Verwendung des TCP/EP-Protokolls fiir die Realisie- 
rung einer einheitlichen Kornmunikadonsinfrastniklur in ei- 
nem Automatisierungssystem bietet eine Reihe von Vortei- 
len. Dem zunehmenden Grad an Komplexitat durch immer 
mehr dezentrale, autarke Funkrionseinheiten kann durch 
Transparenz der Kommunikation entgegengewirkt werden. 
Inbetriebnahmen, Wartungen und Anpassungen der Sy- 
steme konnen erheblich vereinfacht werden. Bereits be- 
wahrte Mechamsmen zur tJbertragung von Daten, zur Fern- 
wartung etc. konnen auf breiter Flache zum Einsatz kom- 
men. Eine groBe Zahl von verfugbaren Softwarewerkzeugen 
auf der Basis des TCP/EP-Protokolls machen viele Spezial- 
losungen uberfliissig. Wie bereits erwahnt lassen sich bei- 
spielsweise Steuenmgsprogranime und andere Daten pro- 
blemlos mit dem FTP-Dienst herunterladen, beliebige Funk- 
rionseinheiten auf der Basis von SNMP warten und System- 
prozesse mit rexec femstarten. . 
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Patentanspriiche 



1. 



Automatisierungssystem umfassend 

- ein erstes physikalisches Netzwerk (17), in dem 
alle angeschlossenen Einrichtungen (IS, 20, 25, 
30) auf der Grundlage eines ersten Kommunikati- 
onsprotokolls kommunizieren konnen und 

— wenigstens ein zweites, fiber eine erste, als Ga- 
teway fungierende Steuereinrichtung (25; 30) mit 
dem ersten Netzwerk verbundenes physikalisches 
Netzwerk (46, 52; 54), in dem alle daran ange- 
schalteten Einrichtungen (25, 58, 59; 30, 54, 56, 
57, 60) auf der Grundlage eines zweiten Kommu- 
nikaiionsprotokolls kommunizieren konnen, wo- 
bei das erste und das zweite Netzwerk (17; 46, 52, 
54) sowie das erste und zweite Kommunikations- 
protokoll verschieden sind, 

d&daunch, gekemizdicBmet, daS jede erste Steuer- 
einrichtung (25, 30) eine logische Schnittstelle zur 
im wesentlichen transparenten Kommunikation 
zwischen wenigstens einer an das erste Netzwerk 
(17) angeschalteten Emrichtung (15, 20, 25, 30) 
und wenigstens einer an das zweite Netzwerk (46, 
52, 54) angeschalteten Emrichtung (50, 58, 59; 
54, 56, 57, 60) auf der Grundlage des ersten Kom- 
munikadonsprotokolls aufweist 
2. Automatisierungssystem nach Anspruch 1, gekenn- 
zeichnet durch wenigstens . eine zweite als Gateway 
fungierende Steuereinrichtung (50), fiber die wenig- 
stens zwei zweite Netzwerke (44, 52) miieinander ver- 
bindbar sind, wobei die zweite Steuer emrichtung (50) 
eine logische Schnittstelle zur im' wesentlichen transpa- 
renten Kommunikation fiber die zweiten Netzwerke 
(46, 52) auf der Grundlage des ersten Kommunikati- 
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onsprotokoUs aufweist 

3. Automatisierungssystem nach Anspruch 1 oder 2, 
dadurch gekennzeichnet, daB das erste Netzwerk ein 
Leitnetzwerk, insbesondere das Ethernet, das zweite 
Netzwerk ein Feldbus, insbesondere ein InterBus-S 5 
nach DIN 19258 ist, und das erste Kommunikations- 
protokoll das TCP/IP-ProtokoU ist 

4. Automatisierungssystem nach Anspruch 3, dadurch 
gekennzeichnet, daB die logischen Schnittstellen der 
ersten und zweiten S teuereinrich tungen jeweils zum to 
Umsetzen eines Datenblocks gemaB dem TCP/IP-Pro- 
tokoll in einen Datenblock gemaB dem zweiten Kom- 
rnunikationsprotokoU, insbesondere des PCP (Periphe- 
ral Communikation Protocol) -ProtokoUs ausgebildet 
ist 15 

5. Automatisierungssystem nach einem der Anspriiche 
1 bis 4, dadurch gekennzeichnet, daB jede Steuerein- 
richtung eine Speichereinrichtung zum Speichem ins- 
besondere von Steuerprogrammen, Diagnosedaten 
iiber das jeweilige zweite Netzwerk und Konfigurati- 20 
onsdaten enthalt. 

6. Automatisierungssystem nach Anspruch 4 oder 5 in 
Verbindung mit Anspruch 3, dadurch gekennzeichnet, 
daB die logische Schnittstelle der ersten Steuereinrich- 
tung eine OCI (Open Com Interface)-SchnittsteUe, ei- 25 
nen DDI-(Device Driver Interface)-Server und eine 
DDI-S chnitts telle zum Empfangen und Verarbeiten 
von iiber das erste Netzwerk empfangenen DDI-Befeh- 
lenumfafit 

7. Automatisierungssystem nach einem der Anspruche 30 
4 bis 6 in Verbindung mit Anspruch 3, dadurch gekenn- 
zeichnet, daB die logische Schnittstelle der ersten und 
zweiten Steuereinrichtung einen FTP (File Transmis- 
sion Protocol) -S erver und -Client zum Empfangen und 
tibertragen von Daten, insbesondere von Steuerungs- 35 
programmen und Konfigurationsdaten sowie einen 
MPM (Multi Port Memory)-Speicher urnfaBt 

8. Automatisierungssystem nach einem der Anspruche 
4 bis 7 in Verbindung mit Anspruch 3, dadurch gekenn- 
zeichnet, daB jeder Steuereinrichtung eine IP-Adresse 40 
zugeordnet ist 

9. Automatisierungssystem nach einem der Anspruche 
1 bis 8, dadurch gekennzeichnet, daB die erste und/oder 
zweite Steuereinrichtung zum Aumehmen wenigstens 
einer Anschaltkarte zum Anschalten eines zweiten 45 
Netzwerkes ausgebildet ist, wobei die Anschaltkarte 
einen Coprozessor enthalt, auf dem die logische 
Schnittstelle implementiert ist, und daB jeder Anschalt- 
karte eine IP-Adresse zugeordnet ist 

10. Automatisierungssystem nach einem der Ansprii- 50 
cfae 1 bis 8, dadurch gekennzeichnet, daB die erste und/ 
oder zweite Steuereinrichtung zum Aufhehmen wenig- 
stens einer Anschaltkarte ausgebildet ist, daB die logi- 
sche Schnittstelle auf einem der jeweUigen Steuerein- 
richtung zugeordneten Stellvertreter-Server implemen- 55 
tiert ist, der wenigstens die virtuelle IP-Adresse der je- 
weiligen Anschaltkarte verwaltet 

11. Automatisierungssystem nach einem der Ansprii- 
che 3 bis 10, dadurch gekennzeichnet, daB jede Steuer- 
einrichtung einen Speicher aufweist, in dem die IP- 60 
Adressen von vorbestimmten iibergeordneten und/oder 
untergeordneten Steuereinrichtungen sowie von vorbe- 
stimmten Einrichrungen, die an wenigstens ein vorbe- 
stimmtes zweites Netzwerk angeschaltet sind, abgelegt 
sind. 65 

12. Automatisierungssystem nach einem der Ansprii- 
che 3 bis 11, dadurch gekennzeichnet, daB dem System 
eine abrufbare Einrichtung zum Speichern der IP- 



Adressen und/oder virtuellen IP- Adressen aller an das 
erste und jedes zweite Netzwerk: angeschlossenen Ein- 
richtungen sowie der ersten und zweiten Steuereinrich- 
tungen zugeordnet ist 

13. Anschaltvorrichtung zum Einsatz in einem Auto- 
matisierungssytem nach einem der Anspruche 1 bis 12, 
die ein erstes physikalisches Netzwerk (17), in dem alle 
angeschlossenen Einrichrungen (15, 20, 25, 30) auf der 
Grundlage eines ersten KommunikationsprotokoUs 
kommunizieren konnen, mit einem zweiten physikali- 
schen Netzwerk (54), in dem alle daran angeschalteten 
Einrichtungen auf der Grundlage eines zweiten Kom- 
munikati onsprotokolls kommunizieren konnen, ver- 
bindet, wobei das erste und das zweite Netzwerk (17, 
54) sowie das erste und zweite Komrnunikationsproto- 
koll verschieden sind, dadurch, gekennzeichnet, daB 
die Anschalteinrichtung (30) eine logische Schnitt- 
stelle zur im wesentlichen transparenten Kommunika- 
tion zwischen wenigstens einer an das erste Netzwerk 
(17) angeschalteten Einrichtung und wenigstens einer 
an das zweite Netzwerk (54) angeschalteten Einrich- 
tung auf der Grundlage des ersten Kommunikations- 
protokoUs aufweist 

14. Anschaltvorrichtung zum Einsatz in einem Auto- 
matisierungssytem nach einem der Anspruche 1 bis 12, 
die wenigstens zwei zweite, einem ersten physikali- 
schen Netzwerk (17), in dem alle angeschlossenen Ein- 
richtungen auf der Grundlage eines ersten Kommuni- 
kationsprotokoUs kommunizieren konnen, untergeord- 
: nete Netzwerke (44, 52), in denen alle daran angeschal- 
teten Einrichtungen auf der Grundlage eines zweiten 
KommunikationsprotokoUs kommunizieren konnen, 
verbindet, wobei das erste und das zweite Netzwerk so- 
wie das erste und zweite KommunikationsprotokoU 
verschieden sind, dadurch, gekennzeichnet, daB die 
Anschalteinrichtung (50) eine logische SchnittsteUe 
zur im wesentlichen transparenten Kommunikadon 
zwischen Einrichtungen, die an den zweiten Netzwer- 
ken angeschaltet sind, auf der Grundlage des ersten 
KommunikationsprotokoUs aufweist 
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